The present invention relates generally to computer networks, and more specifically, to a method and apparatus for auto-configuring layer 3 devices with network configuration parameters.
A computer network typically comprises a plurality of interconnected entities. An entity may consist of any device, such as a host or a node, that xe2x80x9csourcesxe2x80x9d (i.e., transmits) or xe2x80x9csinksxe2x80x9d (i.e., receives) data frames. A common type of network is a local area network (xe2x80x9cLANxe2x80x9d) which typically refers to a privately owned network within a single building or campus. LANs typically employ a data communication protocol (LAN standard), such as Ethernet, FDDI or token ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack), such as the Open Systems Interconnection (OSI) or the Transport Control Protocol/Internet Protocol (TCP/IP) Reference Models. In many instances, LANs of one or more companies, each referred to as a subnetwork, may be interconnected by point-to-point links, microwave transceivers, satellite hook-ups, etc. to form a wide area network (xe2x80x9cWANxe2x80x9d), an internet or a larger network that may span an entire campus, country or continent.
One or more intermediate devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a switch may be utilized to provide a xe2x80x9cswitchingxe2x80x9d function for transferring information, such as data frames, among entities of a computer network. Typically, the switch is a computer and includes a plurality of ports that couple the switch to several LANs and to other switches. The switching function includes receiving data at a source port from an entity and transferring that data to at least one destination port for receipt by another entity.
Switches may operate at various levels of the communication protocol stack. For example, a switch may operate at layer 2 which, in the OSI Reference Model, is called the data link layer. Data frames at the data link layer typically include a header containing the Media Access Control (MAC) address of the entity transmitting the message (source address) and the MAC address of the entity to whom the message is being sent (destination address). To perform the switching function, layer 2 switches examine the MAC destination address of each data frame received on a source port. The frame is then switched onto the destination port or ports associated with that MAC destination address. Layer 2 switches typically do not perform any modification to the data frames being switched and, therefore, are only used to interconnect subnetworks operating the same data link layer standard (e.g., Ethernet).
A MAC address is 48 bits long and is uniquely associated with the network interface card that resides within the entity and provides the connectivity to the network. In particular, each manufacturer of network interface cards is provided with a block of available MAC addresses from a central authority. The manufacturer then assigns to each network interface card a particular MAC address from its authorized block. The MAC address of a particular network interface card thus does not change over time, even though the corresponding entity (or possibly just the network interface card) may be moved from one subnetwork to another. Moreover, upon initialization, an entity may poll its network interface card and learn its MAC address.
Other devices, including switches, may operate at higher communication layers, such as layer three of the OSI Reference Model which is called the network layer. In TCP/IP Model, the network layer corresponds to the Internet Protocol (IP). Data frames at the network or IP layer also include a header. For TCP/IP, the network header contains the IP source address of the entity transmitting the data frame and the IP destination address of the entity to whom the message is being sent. Layer 3 switches typically strip away the data link headers from received data frames to reveal the IP or network header. Layer 3 switches may re-assemble or convert received data frames from one data link format (e.g., Ethernet) to another (e.g. token ring). Thus, layer 3 switches are often used to interconnect dissimilar subnetworks.
Each host or node implementing the TCP/IP protocol stack typically has only one network connection and is therefore assigned a single IP address. A layer 3 switch, however, typically has multiple ports each connected to the network. Associated with each port or physical connection, moreover, may be one or more logical connections or interfaces that provide connectivity between the IP software layer and the data link software layer. These interfaces may each be assigned a different IP address. Thus, a single layer 3 switch typically has many different IP addresses.
An IP version 4 address is 32 bits long and consists of a network number followed by a host number. The network number corresponds to the particular network on which the host resides and is used for routing purposes. The host number is used to address an individual entity located on the corresponding network. Network numbers are assigned from a central authority and each network number uniquely identifies a specific network. Host numbers are assigned by the local network administrator using any desired method. The combination of network number and host number results in a unique IP address across all networks. Nonetheless, unlike MAC addresses, there is nothing inherent in the configuration of an entity (like a particular network interface card) which determines its IP address.
A given network, moreover, may be divided into several parts called subnets for internal routing purposes. With subnets, the original host number is split into a subnet number and a new host number. The resulting IP address now includes a network number (which has not changed), a subnet number and a host number. Each entity on the same subnet has the same subnet number. To entities outside the network subnetting is not visible, since the network number of all entities on all subnets has not changed. Thus, subnetting allows an organization to segregate its various departments (e.g., marketing, engineering, etc.) without having to obtain new network numbers or change any external databases.
To determine which portion of an IP address corresponds to a subnet, a subnet mask is provided. The subnet mask is a 32 bit combination. By ANDing the subnet mask with the IP address, a device, such as a layer 3 switch, may learn the subnet number of the corresponding IP address. The number of available host numbers for a given subnet, moreover, depends on the number of bits selected to represent the subnet number. As additional hosts are added to a subnet, a network administrator may run out of available host numbers, requiring the assignment of a new subnet number and host number to all of the hosts. Also, if a large subnet is assigned to only a few hosts, valuable host numbers will be wasted. Planning for and implementation of subnets is thus an important task which demands substantial time and energy of network administrators.
When an entity wishes to send a message to another entity, upper layers of the communication software build a message packet and hand the packet along with the IP address of the recipient to the IP software layer for transmission. The IP address of the recipient may be learned through the well-known Domain Name System. Before passing the message packet down to the data link layer, the IP layer needs to determine the corresponding MAC address of the recipient. Typically, the IP layer utilizes the Address Resolution Protocol (ARP) to identify a MAC address based on a given IP address. With ARP, a device broadcasts a message asking which entity owns a given IP address. The broadcast will arrive at every entity on the corresponding subnetwork and each entity will check its IP address. The entity having the requested IP address will respond with its MAC address. The IP layer will then use the returned MAC address when handing the message down for further processing by the data link layer.
Another protocol, known as the Reverse Address Resolution Protocol (RARP), is used to identify the corresponding IP address for a given MAC address. With RARP, an entity broadcasts a message asking whether any entity knows the IP address for a given MAC address. RARP is often used by an entity to learn its own IP address by broadcasting a RARP request containing its own MAC address. RARP requests, however, are not forwarded beyond the transmitting entity""s subnetwork. That is, layer 3 switches, which are typically used to interconnect multiple subnetworks, do not forward RARP requests which, by definition, contain a limited broadcast address. Accordingly, a given entity will not receive a reply to its RARP request unless another an entity that knows the requested IP address (e.g., an RARP server) is located on the requester""s subnetwork. To overcome this problem and to allow entities to learn other configuration parameters beyond their IP address, the Bootstrap Protocol (BOOTP) was developed. BOOTP uses the User Data Protocol (UDP) a connectionless transport protocol provided by the TCP/IP Model.
More specifically, the BOOTP protocol defines BOOTP servers, BOOTP clients and BOOTP relay agents. BOOTP servers contain a database of IP addresses manually assigned to various MAC addresses by a network administrator. An entity utilizing BOOTP formulates a UDP request message which is broadcast to an IP address and a predefined BOOTP xe2x80x9cserverxe2x80x9d transport-layer port number. The UDP request is forwarded by BOOTP relay agents (at least one of which is located on each subnetwork) to the BOOTP server. The BOOTP server formulates a UDP reply message to the entity that may be unicast or broadcast along with a predefined BOOTP xe2x80x9cclientxe2x80x9d transport-layer port number. The reply message contains the requesting entity""s IP address as well as other IP or network layer configuration parameters, such as the address and path for a server having a file containing start-up (boot) information, the address of a default router, etc.
An improvement over BOOTP is the Dynamic Host Configuration Protocol (DHCP) which is defined at Request for Comments (RFC) 2131 from the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). DHCP, like BOOTP, is built upon a client-server model, where DHCP servers allocate IP addresses and deliver network configuration parameters to DHCP clients. With DHCP, however, IP addresses are dynamically assigned to hosts upon request from a cache of IP addresses maintained by the DHCP servers. This frees the network administrator from having to manually assign IP addresses. Each IP address, moreover, is only assigned for a limited period of time (referred to as lease). Since IP addresses can be a scarce resource, the utilization of leases prevents entities from keeping IP addresses longer than needed. The DHCP protocol, which also utilizes UDP, defines a set of specific messages that are exchanged between DHCP clients and DHCP servers.
To obtain IP configuration parameters, including an IP address, a DHCP client (e.g., a host or node) broadcasts a DHCPDISCOVER message, which is received and forwarded by DHCP relay agents (similar to BOOTP relay agents) to one or more DHCP servers. The DHCP servers each respond with a DHCPOFFER message that is unicast to the client""s MAC address and offers an IP address with a corresponding lease time, a subnet mask (if applicable) and the IP address of the DHCP server sending the offer, among other information. The DHCP client evaluates the various offers it receives and selects one by broadcasting a DHCPREQUEST message. The selected DHCP server then responds with a DHCPACK message that is unicast to the client officially assigning the selected IP and providing additional network configuration parameters to the client. After receiving its IP address and configuration parameters, a DHCP client is able to exchange messages with any other host on the network. When a host""s lease is about to expire, it may issue another DHCPREQUEST message asking that its lease be extended. The DHCP server may respond with a DHCPACK message granting a new lease time.
DHCP messages, whether originating from a DHCP client or a DHCP server, have the same general format. FIG. 1 is a block diagram of a DHCP message 100. The message 100 includes a plurality of fields, including a 1 octet operation_requested (op) field 102 (e.g., request or reply), a 1 octet hardware_type (htype) field 104 and a 1 octet hardware_address_length (hlen) field 106. Additional fields include a 1 octet hops field 108, which allows configuration via relay agents, and a 4 octet transaction_id (xid) field 110, which is a random number used by the client and the server to associate a set of DHCP messages. Other fields include a 2 octet seconds (secs) field 112, indicating the time elapsed since the client started the configuration process, a 2 octet flags field 114 and a 4 octet client_IP_address (ciaddr) field 116 which is filled in only where the client knows its IP address already. Still other fields include a 4 octet your_IP_address (yiaddr) field 118, which contains the client""s IP address as provided by the DHCP server, a 4 octet server_IP_address (siaddr) field 120, which contains the IP address of a boot server (which may or may not be the server sending the message 100), a 4 octet relay_agent_address (giaddr) field 122, which contains the IP address of the device acting as the host""s relay agent, a 16 octet client_hardware_address (chaddr) field 124, containing the 48 bit MAC address of the client, a 64 octet server_name (sname) field 126 and a 128 octet file_name (file) field 128, which is loaded by the DHCP server with the directory-path name of a file containing IP configuration parameters for use by the client during initialization or boot-up. In addition, the message 100 includes an options field 130 of variable length which may contain any number of options as added by the DHCP server or client. All of the DHCP messages, such as DHCPDISCOVER, DHCPOFFER, DHCPREQUEST and DHCPACK, have the same general format as shown in FIG. 1. In addition, every DHCP message includes a DHCP message type option 132 in options field 130 whose contents identify the corresponding type of DHCP message (e.g., DHCPDISCOVER, DHCPOFFER, etc.).
Although it represents an improvement in the assignment of IP addresses, the DHCP protocol is specifically limited to host computers. That is, DHCP: is neither intended nor designed for use in configuring layer 3 devices. Specifically, layer 3 devices, which are critical to internetwork communication, are typically deemed too important to allow their configuration be manually performed. Thus, although layer 3 devices can act as relay agents passing DHCP messages between DHCP clients and DHCP servers, the switch itself must be manually configured by the network administrator. With the growth in utilization of layer 3 devices, such as layer 3 switches, in many network implementations, however, manual configuration has become time-consuming and remains error prone.
It is an object of the present invention to provide a method and apparatus for automatically configuring layer 3 devices.
It is a further object of the present invention to provide a method and apparatus for dynamically configuring layer 3 devices.
It is a further object of the present invention to provide an extension to the Dynamic Host Configuration Protocol to support the auto-configuration of layer 3 devices.
It is another object of the present invention to allocate and re-assign subnets depending on their utilization.
Briefly, the invention relates to a method and apparatus for auto-configuring layer 3 devices in computer networks. The method relates to a novel extension of the Dynamic Host Configuration Protocol (DHCP). In particular, a DHCP server and one or more layer 3 devices are enhanced to generate, transmit and receive DHCP messages having novel options embedded therein. Through these novel options, a layer 3 device can request and receive from the DHCP server a unique, overall IP address for association with that device. The device may also request and receive one or more IP addresses and corresponding subnets, as necessary, for each of its interfaces. The device may further receive the routing protocols to be used on the various subnets. Accordingly, a layer 3 device may be auto-configured with its IP subnets, IP addresses and routing protocols without the time-consuming, manual programming of a network administrator.
Specifically, the invention includes a novel request/reply option that may be embedded within a DHCP message. The request/reply option preferably includes a type field that may be loaded by a layer 3 device with a particular value depending on the information being requested. That is, by entering different values in the type field, the layer 3 device may request a unique, overall IP address, one or more IP addresses for a particular interface, or a new subnet (and corresponding IP address) for an interface not yet associated with any particular subnet. Another option carries IP address and subnet information for the device""s interfaces. A third option is used to convey routing protocol information between DHCP servers and layer 3 devices. The routing parameter option preferably includes a protocol field. By examining the contents of the protocol field, the layer 3 device learns which routing protocol (e.g., Open Shortest Path First) to use within the associated subnetwork. The invention further includes a new DHCP message type that may be exchanged between layer 3 devices and DHCP servers. The new message type invalidates the device""s network configuration parameters at one or more interfaces, causing it to solicit new IP configuration parameters.
In a further embodiment of the invention, the enhanced DHCP server monitors the utilization of various subnets within the network and adjusts their sizes should the utilization exceed or drop below preset thresholds. For example, if the number of IP addresses assigned to a given subnet falls below 10% of its capacity, the enhanced DHCP server preferably establishes a new subnet that is one-half the size of the original subnet. The enhanced DHCP server then assigns each member-entity of the original subnet a new IP address corresponding to the new subnet. Similarly, if the utilization exceeds 40% of the subnet""s capacity, the enhanced DHCP server preferably establishes a new subnet having approximately twice the size of the original subnet. Again, each member-entity of the original subnet is assigned a new IP address corresponding to the new subnet.
In the preferred embodiment, upon detecting the need for a new subnet whether larger or smaller, the server first assigns a new IP address from the new subnet to each layer 3 device coupled to the old subnet. During the re-assignment process, the layer 3 devices maintain both their old IP address and the new IP address. Next, the server stops renewing leases on the original subnet causing the member-entities to request new IP addresses. In response, the server assigns IP addresses from the new subnet to the member-entities. Next, the server transmits a reconfigure message resulting in the layer 3 device discarding its IP address from the old subnet. The old subnet is then released and made available for re-assignment within the network. As shown and described herein, utilization of present invention allows subnets to be dynamically adjusted depending on their utilization, thereby conserving IP address resources.